Subject: DLSw NetView Support

From: Paul Gacek <[email-masked]>
Date: 25 Jul 93 15:09:30 EDT

NetView Support

A couple of options exist in the way NetView support is effected for a 
DLSw network. These center around where the NetView session (SSCP-PU 
or LU6.2)  is terminated. 

Option 1 - NetView PU in every DLSw box

A NetView PU is resident in each DLSw box. A seperate NetView session
(e.g. SSCP-PU) exists between NetView and each DLSw box in a network.

Advantages
1. Uniform implementation
	a) Each DLSw has same type of support i.e. a NetView PU

Disadvantages 
1. Scalability
	a) Each DLSw must have its NetView PU defined to VTAM
	b) Each NetView PU requires a seperate DLC connection (LLC, SDLC 
..)
2. Implemtation
	Each DLSw box requires a stripped down SNA stack (PC, TC, DFC) 
	and NetView message processor.

Option 2 - Single Gateway NetView PU

A single NetView PU resides in a designated NetView gateway (possibly a 
DLSw box). This DLSw box terminates the NetView session (e.g. SSCP-PU) 
and forwards NetView messages between all the DLSw boxes in a network 
and NetView.

A number of options exist for gateways. Gateways could
	a) convert from NV events to SNMP events
	b) convert from NV events to DLSw management events

Advantages
1. Scalability
	a) Less PUs defined at a host
	b) Less NetView sessions
2. Not all vendors need support NetView PU but can have visibility

Disadvantages
1. Split NetView Support
	Require gateway in some DLSw boxes and client support in others
2. Potentially need protocol between gateway and other DLSw boxes (clients)

---

From: [email-masked] (Matthew H. Gerlach in Cuppertino)
Date: Mon, 26 Jul 93 10:07:41 PDT

Thanks Paul Gacek, 

It is always a pleasure to read a clear and concise comparison of issues
on a Monday morning.

I have a couple of ideas I'd like to throw out.  First of all, from
a network manager's view (the poor person who has to configure everything),
the two approproachs really involve a similar amount of work.  In one
case the manager has to configure a lot of NetView sessions on the host.
In the other case the manager would conceiveably have to configure 
a bunch of somekind of session between the NetView gateway and all of the
DLS switches.  It seems to me that is about the same amount of work.
I guess the network manager is the one to decide which is better, a
bunch of sessions to the host or a bunch of session to a switch.  I'm
not sure which is the best platform to handle a potentially large number
of connections. 

From an implementer's standpoint, I think implementing a mini NetView
stack might be simpler than implementing some level of communcition
between DLS switches and the NetView gateway.  Paul pointed out that
we might "Potentially need protocol between gateway and other DLSw boxes"
Agreeing on said protocol certainly would take more energy than implementing
a mini NetView protocol.  Would we create new DLS message types or have
something completely different?  

One last thought, wouldn't an interesting NetView/DLS gateway simply accept 
NetView connections from other DLS switches and multiplex them onto
a single NetView session to the IBM host?

Matthew H. Gerlach
[email-masked]

---

From: [email-masked] (David Matusow)
Date: Mon, 26 Jul 93 16:32:54 -0400

>   a single NetView session to the IBM host?

Implementing a "mini NetView" is NO little undertaking!  Responding to
the SSCP session is a large undertaking.  Passing some SSP messages
is far simpler and easier to implement.  The SSCP-LU session's
flows are not even architected and fully documented.  I vote to
pass information through the DLSs to a gateway function.

There MIGHT be some definition of the network management for DLSs for
a gateway, but we are speaking of either a name server or passing 
information during connection so this should be minimal, if needed at all.

By using a gateway, this overhead is centered in one location, reducing
the implementation for all other DLSs to only responding to messages
addressed to it.  Passing queued information would not be a big
prospect!

Network management might have a more difficult time depicting the 
configuration of the DLS mesh, but this could be extracted from either
the name server or contact exchanges.  Session awareness would be 
handled by the half-session end LUs, so this would not be a problem.
Leaving only notifying NetView of an outage of the DLS mesh and how
NetView shows this to the customer.  Use of the RUNCMD would be very
helpful to NetView in these cases, as information could be
pulled expressly from a destination/source.

David Matusow
Hypercom